For the last forty years the software market has been built on a payment model involving large upfront fees for perpetual licenses and ongoing support fees. Companies had to purchase their own servers to run the client-server software and hire full-time staff to maintain the software. Consumer software had expensive licensing fees, and was infrequently updated. All of this put most software out of reach for the average small business and consumer. Today, client-server software still requires businesses to hire an internal IT person, or a value-added reseller. These costs still put most technology out of the reach of most small and mid-sized businesses. Today's desktop software is still expensive, and only periodically updated.
In the mid-1990s with the introduction of the World Wide Web, it was realized the World Wide Web could become an extremely cost effective and efficient delivery platform for software applications. Companies began developing applications that were built to be delivered over relatively slow Internet connections versus local area networks. These applications also were developed to support multi-tenancy, which meant thousands or millions of customers could share the same platform bringing tremendous efficiencies of scale. Further, these applications took advantage of the Web's inherent collaborative properties to let millions of people worldwide communicate as if they were on the same network. Applications, such as email and instant messaging, are great examples that leveraged this capability. Additionally, consumer applications, such as social networking services, were created to offer consumers new applications over the Web. This market is called Software as a Service (SaaS) and the applications are delivered for rent or free. Most of the applications are offered for free, and thus the challenge for developers of Web-based applications is how to generate revenue.
Consumers and small business customers largely have expected the Internet to be free and as a result have shown a huge resistance towards paying for content, with limited exceptions. Additionally, they have shown a resistance towards paying for Web-based applications, such as email and instant messaging. As a result, today thousands of Web-based applications offer primarily free services to consumers.
Instead, consumers and small businesses have been willing to accept viewing of advertising and sharing personal information with these free applications and content. Accordingly, in the SaaS market many companies have been trying to monetize their software applications with advertising revenue from third-party advertisers.
Currently, there are two primary methods for Internet advertising within an application that together represents more than eighty percent of online advertising: Cost Per Thousand Impressions (CPM) banner and display advertisements; and Cost Per Click (CPC) text and contextual ads. Both of these methods have significant limitations and downsides, including interfering with the user experience by taking up valuable screen real estate to place the advertising and invading the privacy of a user by scanning personal data as a means to understand relevance and then display ads. Additionally, neither of these methods works well in Web-based applications and they are viewed as detracting from the application by the user. Further, none of these prior methods alone maximize the potential for revenue generation.
Another emerging option is to integrate third-party partners into an application, sell consumers the premium product or service from the integrated third-party partner, and then generate revenue on a Cost Per Action (CPA) model. To achieve this, developers must manually and individually integrate each third party Web-based application, Web service, and online merchant into the application which is a difficult process. In particular, this integration process requires developing and integrating a reporting layer, a billing layer, a user interface framework, and other infrastructure necessary to support each third-party partner into the application. Most third party partners have limited or no Application Programming Interfaces (“APIs”) making integration even more complicated.
It is equally difficult for application, Web service, and online merchant providers that wish to utilize third-party Web-based software applications as a distribution channel. They face significant challenges to achieve a wide syndication of their offerings. Typically, they have limited technological sophistication and lack the robust API's needed to simplify integration. Further, they are forced to individually integrate with each Web-based application, spending a large amount of technical and financial resources to achieve distribution.
Prior APIs have lacked the ability to easily and properly integrate a third-party Web-based feature into an application and have only been able to handle programmatic functions. Additionally, these prior APIs have been completely unaware of workflow which is critical to being able to integrate a feature into the right step(s) of a process of a user performing a given task in an application. Further, they have lacked any definition of the user interface. As a result, a provider of a feature has had little to no control over how a feature is integrated or how it looks to the user in an application.
This inability to easily and properly integrate a feature presents several major problems. For example, these integration difficulties often result in a poor workflow and a poor user interface which decreases usage and revenue generation with the feature. Additionally, these integration difficulties which cause the workflow and user interface issues often seriously damage the brand associated with the provided feature because of the poor resulting performance.